OpenEdge Getting Started:<br />Core Business Services What you can audit

Database events — Record-level events (CREATE, UPDATE, DELETE).

Internal events — Authentication (login), schema changes, audit policy administration, security administration, and database utilities.

Application events — Application context or application-defined events.

Auditing database events

Creating, updating, or deleting records on a database table are all considered database events. If you want to audit a database, you must audit-enable the database, create a policy, configure table and field events, and enable the events whose audit data you want to record.

When you audit-enable a database, all internal tables used by OpenEdge auditing are created. However, if you audit-enable a database but do not configure a policy to audit any of its table or field events, no auditing takes place, even though the internal tables necessary for auditing are in place.

To audit database table and field events, you must set up auditing in the database where the schema for those tables and fields is defined; in other words, the audit policy for a database’s events will always be recorded in the database where the tables and fields reside. The initial capture of the data must always be where the schema resides. You can later move the audit data into a designated archive, provided that you have audit data archiver privileges.

You can selectively configure OpenEdge database auditing per database, per database table, and per database table field. Within the database table and field categories, you can configure auditing for any combination of create, update, and delete operations, as well as control how much information is recorded about each of these operations. For example, you can simply record the fact that something occurred in a table, or you can record what actually changed, as well as the old and new field values. By default, OpenEdge records field value information in a streaming format; you can optionally choose instead to record each single field value in a separate record.

When you set up database auditing, you can choose different audit-level settings for specific fields, even ones in the same table. Field-level settings always take precedence over table-level defaults. Any fields for which you do not specify particular audit settings retain the default settings for the table to which they belong; any fields for which you do specify individual audit settings are audited based on those unique settings.

If you configure auditing of database events, the audit data that is recorded provides the following information: which authenticated user was set for the database connection; the available database transaction IDs; the name of the table and field (if applicable) for which an operation occurred; what type of operation (create, update, or delete) occurred; and, optionally, the old and new values for any modified fields.

You can optionally include references to application context and user login context events captured by application auditing. This will give your database events context relating the database operation to an application operation. For more information, see the "Setting up OpenEdge auditing context" section.

Auditing internal system events

Tasks such as creating a user account, deleting a database administrator account, and updating a table trigger are all considered internal system events. When you audit-enable a database, the audit schema is created in the database and the internal event definition data is populated. What this means is that the name and the event ID for all Progress-defined, internal system events are automatically loaded. (All event ID numbers below 32000 are reserved for OpenEdge events.)

From that point, it is up to you to audit-enable the events you want to record. In other words, although the Database record create event with the ID of 5100 is automatically added to the database event definition, you must specifically enable the audit event 5100 in the audit policy.

Provided with OpenEdge Release 10.1A are several preconfigured audit policies that define field and table policy for internal events. These policies are similar to policies you would use to audit application database events. When you load the preconfigured policies, the policies are automatically activated. You can review the policies once you import them; then, if you want, you can deactivate any of them. You must then commit the changes brought about by importing and activating (and deactivating, if applicable) the policies in order to install those policies in each OpenEdge database and make them ready for use. Once you do so, auditing begins. For more information about these policies, see Appendix B, "Preconfigured Audit Policies" and the Audit Policy Maintenance Help.

With the exception of audit archive events, all audited events are driven by table policy.

Auditing application events

Application events include application-context and application-defined events. You must enable application-context events and insert code into the application to trigger the events to be recorded. For application-defined events, you must define and enable the events, and then you must insert code into the application to trigger the events to be recorded.

You can define application events to be stored in the same database where an application’s database events are recorded or in a database used specifically for application events; or you can record the events in any combination of an application’s connected databases.

Application-defined events — Allows you to create your own application events for which there is no corresponding database operation; allows you to have full control over the granularity and detail of the audit data recorded; and allows you to group events into ranges for simplification of reporting.

Audit event groups — Allows you to define (within the application) audit event groups, which can be used to establish a collection of related application or database audit events. For example, starting an update on a DataSet as part of a business task might change multiple table records in multiple databases. By starting and ending an audit event group around the DataSet UPDATE operation, you can later audit all audit event records that were involved in that single application operation.

Application context — Allows you to record what application or business task the user was performing when the auditing event occurred. In viewing the context in which a change occurred, you can better determine whether the change was legitimate.